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A distributed system is 
susceptible to a variety 

of security threats 
mounted by intruders. 
We describe a number 
of protocols to 

authenticate users, 
hosts, and processes. 



distributed system — a collection of hosts interconnected by a network — 
poses some intricate security problems. A fundamental concern is au- 
thentication of local and remote entities in the system. In a distributed 
system, the hosts communicate by sending and receiving messages over the 
network. Various resources (like files and printers) distributed among the hosts 
are shared across the network in the form of network services provided by servers. 
Individual processes (clients) that desire access to resources direct service requests 
to the appropriate servers. Aside from such client-server computing, there are 
many other reasons for having a distributed system. For example, a task can be 
divided into subtasks that arc executed concurrently on different hosts. 

A distributed system is susceptible to a variety of threats mounted by intruders 
as well as legitimate users of the system. Indeed, legitimate users aTe more 
powerful adversaries, since they possess internal state information not usually 
available to an intruder (except after a successful penetration of a host). We 
identify two general types of threats. 

The first type, host compromize, refers to the subversion of individual hosts in a 
system. Various degrees of subversion arc possible, ranging from the relatively 
benign case of corrupting process state information to the extreme case of assum- 
ing total control of a host. Host compromise threats can be countered by a 
combination of hardware techniques (like processor protection modes) and soft- 
ware techniques (like reference monitors). Because these techniques are outside 
our scope, we refer interested readers to Denning 1 for an overview of computer 
systems security. Here, we assume that each host implements a reference monitor 
that can be trusted to properly segregate processes. 

The second type, communication compromise, includes threats associated with 
message communications. We subdivide these into 

•(T1), eavesdropping of messages transmitted over network links to extract 
information on private conversations; 

• (17), arbitrary modification, insertion, and deletion of messages transmitted 
over network links to confound a receiver into accepting fabricated messages; 
and 

• (T3), replay of old messages (a combination of (Tl) and (T2)). 
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(Tl) is a passive threat, while (T2) 
and (T3) are active. A passive threat 
does not affect the system being threat- 
ened, whereas an active threat does; 
Therefore, passive threats are inherent- 
ly undetectable by the system and can 
only be dealt with by using preventive 
measures. Active threats, on the other 
hand, are combated by a combination 
of prevention, detection, and recovery 
techniques. We will not consider threats 
of "traffic analysis" and * denial of ser- 
vice" because they are more relevant to 
the general security of a distributed sys- 
tem than lo our restricted setting of 
authentication. 

Some basic security requirements can 
be formulated. For example, secrecy 
and integrity arc two common require* 
ments for secure communication. Se- 
crecy specifies that a message can be 
read only by its intended recipients, while 
integrity specifies that every message is 
received exactly as it was sent, or a 
discrepancy is detected. 

A strong cryplosyNlem can provide a 
high level of assurance for secrecy and 
integrity (see "Basic cryptography" side- 
bar). More precisely, an encrypted mes- 
sage provides no information regarding 
the original message, hence guarantee- 
ing secrecy; and an encrypted message, 
if tampered with, would not decrypt 
into a legal message, hence guarantee- 
ing integrity. 

Replay of old messages can be coun- 
tered by using nonces or time stamps. 1 - 
A nonce is information thai is guaran- 
teed fresh, that is, it has not appeared or 
been used before. Therefore, a reply 
that contains some function of a recent- 
ly sent nonce should be considered time- 
ly because the reply could have been 
generated only after the nonce wassent. 
Perfect random numbers are good nonce 
candidates; however, their effectiveness 
is dependent upon the randomness that 
is practically achievable. Time stamps 
are values of a local clock. Their use 
requires at least some loose synchroni- 
zation of all local clocks, and hence 
their effectiveness is also somewhat re- 
stricted. 

What needs 
authentication? 

In simple terms, authentication is iden- 
tification plus verification. Identifica- 
tion is the process whereby an entity 




Figure 1. Principals in a distributed 



system. 



claims a certain identity, while verifica- 
tion is the process whereby that claim is 
checked. Thus, the correctness of an 
authentication relies heavily on the ver- 
ification procedure employed. 

The entities in a distributed system 
that can be distinctly identified are col- 
lectively referred lo ^'principals. There 
are three main types of authentication 
in a distributed computing system: 

• {Al). message content authentica- 
tion — verifying that the content of 
a received message is the same as 
when it was sent; 

• (A2). message origin authentication 
— verifying that the sender of a 
received message is the same one 
recorded in the sender field of a 
message: and 

•(A3), general identity authentica- 
tion — verifying that a principal's 
identity is as claimed. 

( Al) is commonly handled by tagging 
a key-dependent message authentica- 
tion code (MAC) onto a message be- 
fore it is sent. Message integrity can be 
confirmed upon reception by recom- 
puting the MAC and comparing it with 
the one attached. (A2) is a subcase of 
(A3). A successful general identity au- 
thentication usually results in a belief 
held by the authenticating principal (the 
verifier) that the authenticated princi- 
pal (the claimant ) possesses the claimed 
identity. Hence, subsequent claimant 
actions are attributable to the claimed 
identity; for example, general identity 
authentication is needed for both au- 
thorisation and accounting functions. 
Here, we restrict our attention togener- 
al identity authentication. 

In an environment where both host 
and communication compromises can 
occur, principals must adopt a mutually 
suspicious attitude. Therefore, mutual 
authentication, whereby both commu- 



nicating principals verify each other's 
identity, rather than one-way authenti- 
cation, whereby only one principal ver- 
ifies the identity of the other principal, 
is usually required. 

In a distributed computing environ- 
ment, authentication is carried out us- 
ing a protocol involving message ex- 
changes. We refer to these protocols as 
authentication protocols. 

Most existing systems use only very 
primitive authentication measures or 
none at all. For example. 

•The prevalent login procedure re- 
quires users to enter their passwords in 
response to a system prompt. Users are 
then one-way authenticated by verify- 
ing the (possibly transformed) password 
against an internally stored table. How- 
ever, no mechanism lets users authen- 
ticate a system. This design is accept- 
able only when the system is trust- 
worthy, or the probability of compro- 
mise is low. 

• In a typical client-server interaction, 
the server — on accepting a client's 
request — has lo trust that (1) the resi- 
dent hosl of the client has correctly 
authenticated the client and (2) the iden- 
tity supplied in the request actually cor- 
responds lo Ihe client. Such trust is valid 
only if the system's hosts are trustwor- 
thy and its communication channels are 
secure. 

These measures are seriously inade- 
quate because the notion of trust in 
distributed systems is poorly understood. 
A satisfactory formal explication of trust 
has yet to be proposed: Second, the 
proliferation of large-scale distributed 
systems spanning multiple administra- 
tive domains has produced extremely 
complex trust relationships. 

In a distributed computing system, 
the entities that require identification 
are hosts, users, and processes. 3 They 
thus constitute the principals involved 
in an authenticalion, which we describe 
(also see Figure 1). 

Hosts. These are addressable entities 
a I Ihe network level. A host is distin- 
guished from its underlying supporting 
hardware. For example, hosl H running 
on workstation A can be moved to work- 
station B by performing the bootstrap 
sequence for // on H. A hosl is usually 
identified by its name (for example, a 
domain name) or its network address 
(for example, an Internet address). 
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Basic cryptography 



A crypt osystem comes with one procedure tor encryption 
and another for decryption. A formal description of a crypt o- 
6ystem includes specifications tor message, key, and doner* 
text spaces, and encryption and decryption functions. 

There are two broad classes of crypiosystems, symmetric 
and asymmetric. 1 In the lormer, encryption and decryption 
keys are the same and hence must be kept secret. In the lat- 
ter, the encryption key differs from the decryption key, and . 
the decryption key is kept eecnrt.The encryption key, howev- 
er, can be made public. Consequently, tt Is Important that no 
one be able to determine the decryption key from the encryp- 
tion key. Symmetric and asymmetric cryptosystems are also 
referred to as shared key and public key cryptosystems, re- 
spectively. . 

Knowledge of the encryption key allows one to encrypt arbi- 
trary messages from me message space, while knowledge of 
the decryption key allows, one to recover a message from its 
encrypted form. Thus, the encryption and decryption func- 
tions satisfy the following relation: Mis the message apace, 
K e x K 0 Is the set of 'encryptionAtecryption key pairs: 

Vmc Aft V (*, *')« Kf> Ko: {{mU^ « m (CI) 

where [x) r denotes the encryption operation on message jc rf y 
is an encryption key and the decryption operation on x H y is 
a decryption key. {In the case of a symmetric crypt osystem 
wtth Identical encryption and decryption keys, the operation 

should be dear from the context.) 

Two widely used cryploeyBtems are the Data Encryption 
Standard {DES V a symmetric system, and BSA,' an asym- 
metric system. In RSA, encryption-decryption key pairs satis- 
fy the following commutative property*: 



V m e At. V (*, *") € Ke x {(m),-i}»p m (C3) 

hence yielding a signature capability. That Is, suppose k and 
Jr' are Pb asymmetric keys, then (m)^? can be used as Pa 
signature on m since H could only have been produced by P, 
the only principal that knows Jr'. By (C2), Ps signature Is 
verifiable by any principal with knowledge of Ac, Ps public key. 
Note that in <C2), the roles of * and Jr 1 are reversed; speeffi- 
catty, k* Is used as an encryption key whRe k functions as a 
decryption key. To avoid confusion wrih the more typical roles 
for k and Ar" 1 as exemplified In (CI), we refer to encryption by 
as a signing operation. In this article, asymmetric crypto- 
systems are assumed to be commutative. 

Since. In practice, symmetric cryptosystems can operate 
much taster than asymmetric ones, asymmetric cryptosys- 
tems are often used only for InHiat'tzation/controt functions, 
while symmetric cryptosystems can be used for both inrUai- 
rzattons and actual data transfer. 
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whereas a particular host hardware is 
usually identified by its factory-assigned 
serial number (for example, a worksta- 
tion on an Ethernet can be identified by 
the unique address of its Ethernet adapt- 
er board). 

Users. These entities are ultimately 
responsible for all system activities. In 
other words, users initiate and are ac- 
countable for all system activities. Most 
access-control and accounting functions 
arc based on users. (For completeness, 
a special user called wot can be postu- 
lated, who is accountable for system- 
level activities like process scheduling.) 
Typical users include humans, as well as 
accounts maintained in the user data- 
base. Note that users are considered to 
be outside the system boundary. 

Processes. The system creates pro- 
cesses within the system boundary to 
represent users. A process requests and 



consumes resources on behalf of its 
unique associated user. Processes fall 
into two classes: client and server. Cli- 
ent processes are consumers who ob- 
tain services from server processes, who 
arc service providers. A particular pro- 
cess can act as both a client and a server. 
For example, print servers are usually 
created by (and hence associated with) 
the user root and act as servers for print- 
ing requests by other processes. How- 
ever , they act as clients when requesting 
files from file servers. 

Authentication 
exchanges 

We identify the following major types 
of authentication exchanges in a dis- 
tributed system. 

Host-host. Host-level activities often 



require cooperation between hosts. For 
example, individual hosts exchange link 
information for updating their internal 
topology maps. In remote bootstrap- 
ping, a host, upon reinitialization, must 
identify a trustworthy boot server to 
supply the information (for example, a 
copy of the operating system) required 
for correct initialization. 

User-host. A user gains access to a 
distributed system by logging in a host 
in the system. In an open-access envi- 
ronment where hosts are scattered across 
unrestricted areas, a host can be arbi- 
trarily compromised, necessitating mu- 
tual authentication between the user 
and host. 

Process-process. Two main subclass- 
es exist: 

• Peer-process communication. Peer 
processes must be satisfied with each 
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other's identity before private commu- 
nication can begin. 

•Client-server communication. An 
access decision concerning a client's 
request can be made only when the 
client's identity is affirmed. A client is 
willing to surrender valuable informa- 
tion to a server only after verifying the 
server's identity. 

As shown later, these two classes of 
communication authentication relate 
closely and can be handled by similar 
protocols. 

From now on, we use authentication 
to refer to general identity authentica- 
tion. 

Paradigms of 
authentication 
protocols 

Authentication in distributed systems 
is always carried out with protocols. A 
protocol is a precisely defined sequence 
of communication and compulation 
steps. A communication step transfers 
messages from one principal (sender) 
to another (receiver), while a computa- 
tion step updates a principal's internal 
slate. Two distinct slates can be identi- 
fied upon protocol termination, one sig- 
nifying successful authentication and the 
other failure. 

Although the goal of any authentica- 
tion is to verify the claimed identity of a 
principal, specific success and failure 
states are highly protocol dependent. 
For example, the success of an authen- 
tication during the connection estab- 
lishment phase of a communication pro- 
tocol is usually indicated by the 
distribution of a fresh session key be- 
tween two mutually authenticated peer 
processes. On the other hand, in a U6er 
login authentication, success usually 
results in the creation of a login process 
on behalf of the user. 

We present protocols in the following 
format. A communication step where- 
by P sends a message M to Q is repre- 
sented as P -> Q: M , whereas a compu- 
tation step of P is written as P: 
where . is a specification of the 
compulation step. For example, the typ- 
ical login protocol between host W and 
user U is given below (/ is a one-way 
function; that is, given y, il is computa- 
tionally infeasible to find an x such that 



U-*H : U 

H -* U: "Please enter password" 
/7->N: p 

H :. compute y = f(p) 

: retrieve user record 

j i {password v )) from user 
database 
: if y = /(password ti ) then 
accept; otherwise reject 

We next examine the key ideas that 
underlie authentication protocol design 
by presenting several protocol para- 
digms. 

Since authentication protocol para- 
digms directly use cryptosystems. their 
basic design principles also follow closely 
the type of cryptosystem used. 

Note that the protocol paradigms il- 
lustrate basic design principles only. A 
realistic protocol is necessarily a refine- 
ment of these basic paradigms and ad- 
dresses weaker environment assump- 
tions, stronger postconditions, or both. 
Also, a realistic protocol may use both 
symmetric and asymmetric cryptosys- 
tems. 

Protocols based upon symmetric 

cryptosystems. In a symmetric crypto- 
system, knowing the shared key lets a 
principal encrypt and decrypt arbitrary 
messages. Without such knowledge, a 
principal cannot obtain the encrypted 
version of a message or decrypt an en- 
crypted message. Hence, authentication 
protocols can be designed according to 
the (SYM) principle: // a principal can 
correctly encrypt a message using a key 
that the verifier believes is known only to 
a principal with the claimed identity ( out- 
side of the verifier), this act constitutes 
sufficient proof of identity. 

Thus (SYM) embodies the proof-by- 
knowledgc principle for authentication, 
that is, a principal's knowledge is indi- 
rectly demonstrated through encryption 
(see "Approaches to authentication** 
sidebar). Using (SYM), we immediate- 
ly obtain the following basic protocol (k 
is a symmetric key shared between P 
and Q). 

P : create m = "1 am PS 
: compute m' = \m\ k 

P -» Q : m,m' 

Q : verify [m\ k = m* 

: if equal then accept; 
otherwise Teject 

Clearly, the (SYM) design principle 
is sound only if the underlying crypto- 



system is slrong (one cannot find the 
encrypted version of a message without 
knowing the key) and the key is secret 
(it is shared only between the real prin- 
cipal and the verifier). Note thai this 
protocol performs only one-way authen- 
tication. Mutual authentication can be 
achieved by reversing the roles of P 
and Q. 

One major weakness of the protocol 
is its vulnerability to replays. More pre- 
cisely, an adversary could masquerade 
as P by recording the message m' and 
later replaying it to Q. As mentioned, 
replay attacks can be countered by us- 
ing nonces ot time stamps. We modify 
the protocol by adding a challenge-and- 
responsestep using nonces (n is a nonce). 

P->Q: "lam/V* 
Q->P: n 

P : compute «' = \n\ t 
P-*Q:n' 

Q : verify \n\ k = n' 

: if equal then accept; 
otherwise reject 

Replay is foiled by the freshness of n. 
Thus, even if an eavesdropper has mon- 
itored all previous authentication con- 
versations between P and QM still could 
not produce the correct n'. (This also 
points out the need for the cryptosys- 
tem to withstand known plainlexl at- 
tack. In other words, the crypiosystem 
must be unbreakable given the knowl- 
edge of plaintext-ciphertext pairs.) The 
challenge-and-response siep can be re- 
peated any number of times until the 
desired level of confidence is reached 
by Q. 

This protocol is impractical as a gen- 
eral large-scale solution because each 
principal must store in memory the se- 
cret key for every other principal il would 
ever want to authenticate. This presents 
major initialization (the predistribution 
of secret keys) and storage problems. 
Moreover, the compromise of one prin- 
cipal can potentially compromise the 
entire sysiem. These problems can be 
significantly reduced by postulating a 
centralized authentication server /4 that 
shares a secret key k x with every princi- 
pal X in the system. 2 The basic authen- 
tication protocol then becomes 

P~>Q: "1 amr 
Q-*P: n 

P : compute n = |n| 4> 
P->Q : n 

Q : compute n" = |P, n\ Q 
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Approaches t authentication 

All authentication procedures involve checking known information about a 
claimed identity against information acquired from the claimant during the Identi- 
ty-verification procedure. Such checking can be based on the following three ap- 
proaches. 1 

Proof by knowledge. The claimant knows information regarding the claimed 
identity that can only be known or produced by a principal with that identity. For 
example, password knowledge is necessary to most login procedures. A proof by 
knowledge can be conducted by a direct demonstration, like typing m a pass- 
word, or by an indirect demonstration, such as correctly computing replies to veri- 
fier challenges. Direct demonstration is not preferable from a security viewpoint 
since a compromised verifier can record the submitted knowledge and later im- 
personate the cla tenant by presenting the recorded knowledge. Indirect demon- 
strallon can be designed to Induce high confidence in the verifier without leaving 
any clue to how the claimant's replies are computed. For example, Feige, Flat, 
and Shamir* propose a zero-knowledge protocol for proof of identity. This proto- 
col a Bows claimant Cto prove to verifier Vthat C knows how lo compute replies 
to challenges without revealing the replies. These protocols are provabty secure 
(under complexity assumptions). However, additional refinements are needed be- 
fore they can be applied In practical systems. 

Proof by possession. The claimant produces Bn Item that can only be pos- 
sessed by a principal with the claimed identity, tor example, an 10 badge. The 
item has to be unforgeable and saleiy guarded. 

Proof by property. The verifier directly measures certain claimant properties 
with such biometric techniques as fingerprint and retina print The measured 
property has to be distinguishing, that is. unique among all possible principals. 

p roo t oy Knowledge and possession (and combinations thereof) can be appBed 
to all types of authentication needs in a secure distributed system, while proof by 
property is generally limited to the authentication of human users by a host 
equipped with specialized measuring instruments. 
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(2-4/4: #T 

A : recover (/>, n') from n" by 
decrypting with ko 
: compute m = (ln'| k ,, fco 
A -> Q : m 

Q : verify [n^m 

: if equal then accept; 
otherwise reject 

Thus Q's verification step is preceded 
by A's key translation step. The proto- 
col correctness now also rests on A's 
trustworthiness — that A will properly 
decrypt using P's key and reencrypt us- 
ing g's key. The initialization and stor- 
age problems are greatly alleviated be- 
cause now each principal needs to keep 
only one key. The risk of compromise is 
mostly shifted to A t whose security can 
be guaranteed by various measures , such 
as encrypting stored keys using a master 
key and putting A in a physically secure 
room. 

Protocols based upon asymmetric 
cryptosystems. In an asymmetric crypt- 
osystem, each principal P publishes its 
public key k r and keeps secret its pri- 
vate key Thus only P can generate 
(m|,-. for any message m by signing it 
using k} \ The signed message [m] k p can 
be verified by any principal with knowl- 
edge of k, (assuming a commutative 
asymmetric cryptosystem). The basic 
design principle is (ASYM): If a princi- 
pal can correctly sign a message using 
the private key of the claimed identity, 
this act constitutes sufficient proof of 
identity. 

This (ASYM) principle follows the 
proof-by-knowledge principle foi au- 
thentication, in that a principal's knowl- 
edge is indirectly demonstrated through 
its signing capability. Using (ASYM), 
we obtain a basic protocol as follows (n 
is a nonce): 

P -* Q: "1 am />." 
Q-*P : n 

P : compute V = \n\ k} % 
P-*Q:n' 

Q : verify n = \n\ 

: if equal then accept; 
otherwise reject 

This protocol depends on the guaran- 
tee that [n) k f cannot be produced with- 
out the knowledge of k? and the cor- 
rectness of *> as published by P and 
kept by Q. 

As in protocols that use symmetric 
keys, the initialization andstorage prob- 



lems can be alleviated by postulating a 
centralized certification authority A that 
maintains a database of all published 
public keys. The protocol can then be 
modified as follows: 

P-*Q: "lam/V* 
Q-*P: n 

P : compute n' = [n]^ 
P->Q:n' 

Q-*A: "I need P's public key.* 
A : retrieve c = \P t k£k+ from 

key database 
A -» Q : P, c 

Q : recover (?, *,) from c by 
decrypting with k A 



: verify n ^ ln')^ 
: if equal then accept; 
otherwise reject 

Thus public key certificate c repre- 
sents a certified statement by A that P's 
public key is k r Other information such 
as a specified lifetime and the classifica- 
tion of principal P (for mandatory ac- 
cess control) can also be included in the 
certificate (such information is omitted 
here). Each principal in the system need 
only keep a copy of the public key k A of 
A. 

In this protocol, A is an example of an 
on-line certification authority, which 
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supports interactive queries and is ac- 
tively involved in authentication ex- 
changes. A certification authority can 
also operate off line so that a public key 
certificate is issued to each principal 
only once. The certificate is kept by the 
principal and forwarded during an au- 
thentication exchange, thus eliminating 
the need to query A interactively. Al- 
ternatively, the certificate can be kept 
in an on-line database that is publicly 
accessible. Forgery is impossible, since 
a certificate is signed by the certifica- 
tion authority. 

Notion of trust. Correctness of both 
types of protocol paradigms requires 
more than the existence of secure com- 
munication channels between principals 
and the appropriate authentication serv- 
ers (or certification authorities). In fact, 
such correctness is critically dependent 
on the capability of the servers (author- 
ities) to faithfully follow the protocols. 
Each principal bases its judgment on its 
own observations (messages sent and 
received) and its trust of the server's 
judgment. 

In some sense, less trust is required of 
a certification authority than of an au- 
thentication seTveT, because all infor- 
mation kept by the authority is public 
(except for its own private key). Fur- 
thermore, a certification authority has 
no way of masquerading as a principal 
because a principal's private key is not 
shared. 

Our forma) understanding of trust in 
a distributed system is at best inade- 
quate. In particular, a formal under- 
standing of authentication would re- 
quire both a formal specification of trust 
and a rigomus reasoning method where- 
in trust is a basic element. 

Authentication 
protocol failures 

Despite the apparent simplicity of the 
basic design principles for authentica- 
tion protocols, designing realistic pro- 
tocols is notoriously difficult. Several 
published protocols have exhibited sub- 
tle security problems. 1 * 2 -* 

Several reasons for this difficulty ex- 
ist. Most realistic cryptosystems satisfy 
algebraic identities additional to those 
in (CI) and (C2). These extra proper- 
ties may generate undesirable effects 
when combined with protocol logic. 



Despite the apparent 
simplicity of basic design 
principles for authentication 
protocols, designing realistic 
protocols is notoriously 
difficult. 



Second, even assuming thai the under- 
lying crypiosystem is perfect, unexpect- 
ed interaction among the protocol steps 
con lead to subtle logical flaws. Third, 
assumptions regarding the environment 
and the capabilities of an adversary are 
not explicitly specified, making it ex- 
tremely difficult to determine when a 
protocol is applicable and what final 
states are achieved. 

Wc illustrate the difficulty by show- 
ing an authentication protocol proposed 
by Need ham and Schroeder 2 that con- 
tains a subtle weakness.' Symmetric keys 

and k 0 aTC shared between P and A , 
and Q and A, respectively, where A is 
an authentication server. Let k be a 
session key. 

(1) P -> A: P.Q,n f 

(3) P-»G:(fc,a v 

(4) Q -* P: K) 4 

(5) K+U* 

The message (*, P) itf in step 3 can only 
be decrypted, and hence understood, by 
Q. Step 4 reflects Q\ knowledge of k, 
while step 5 assures Q of /**s knowledge 
of k\ hence the aulhcniicatinn hand- 
shake is based entirely on knowledge of 
k. The subtle weakness in the protocol 
arises from the fact that the message {*, 
P\ to sent in step 3 contains no informa- 
tion for Q to verify its freshness. (Note 
thai only P and A know k to be fresh.) In 
fact, this is the first message sent to Q 
about P's intention to establish a secure 
connection. An adversary who has com- 
promised an old session key k* can im- 
personate P by Teplaying the recorded 
message |*', P) kQ in step 3 and subse- 
quently executing steps 4 and 5 using k'. 

To avoid protocol failures, formal 
methods may be employed in Ihc design 
and verification of authentication pro- 
tocols. A formal design method should 
embody the basic design principles as 



illustrated in the previous section. In 
addition, informal reasoning should De- 
formalized within a verification meth- 
od. Such informal reasoning would in- 
clude statements like ~H you believe 
that only you and Bob know Ac. then you 
should believe any message you receive 
encrypted with k was originally sent by 
Bob," which must be formally speci- 
fied. 

Early attempts at formal verification 
of security protocols mainly follow an 
algebraic approach. 9 Messages ex- 
changed in a protocol are viewed as 
terms in an algebra. Various identities 
involving the encryption and decryp- 
tion operators (for example, (Cl) and 
(C2)) are taken to be term-rewriting 
rules. A protocol is secure if it is impos- 
sible to derive certain terms (for exam- 
ple, the term containing the key) from 
the terms obtainable by an adversary. 
The algebraic approach is limited. since 
it has been used mainly to deal with one 
aspect of security, namely secrecy. Re- 
cently, logical approaches have been 
proposed to study authentication pro- 
tocols. 4 Most of these logics adopt a 
modal basis, with belief and knowledge 
as central notions. The logical approach- 
es appear to be more general than the 
algebraic ones, but they lack the rigor- 
ous foundation of more well-estab- 
lished systems like first-order and tem- 
poral logics. A satisfactory semantic 
model for these systems has not been 
developed. Much research is needed to 
obtain sound design methods and to 
formally understand authentication is- 
sues. 

Authentication 
framework 

We synthesize basic concepts into an 
authentication framework that can be 
incorporated into the design of secure 
distributed systems. We identify five 
aspects of secure distributed system 
design and the associated authentica- 
tion needs. (This section is not exhaus- 
tive in scope because other issues may 
have to be addressed in an actual dis- 
tributed system security framework. 
Also, the presented protocols are not 
meant to be definitive or optimal.) The 
five aspects are 

• Most initializations. All process ex- 
ecutions lake place inside hosts. Some 
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hosts (like workstations) also act as sys- 
tem-entry points by allowing user log- 
ins. The overall security of a distributed 
system is highly dependent on the secu- 
rity of each host. However, in an open 
network environment, not all hosts can 
be physically protected. Thus resist ance 
to compromise must be built into a host's 
software to ensure secure operation. 
This suggests the importance of host 
software integrity. Loading a host that 
employs remote initialization with the 
coned host software is necessary to its 
proper functioning. In fact, one way to 
compromise a public host is to reboot 
the host with incorrect initialization in- 
formation. Authentication can be used 
to implement secure bootstrapping. 

• User logins. User identity is estab- 
lished at login, and all subsequent user 
activities are attributed to this identity. 
All access-control decisions and account- 
ing functions are based on this identity. 
Correct user identification is thus cru- 
cial to the functioning of a secure sys- 
tem. Since any host in an open environ- 
ment is susceptible to compromise, a 
user should not engage in any activity 
with a host without first ascertaining 
the host's identity. A mutual user-host 
authentication can achieve the required 
guarantees. 

• Peer communications. Distributed 
systems can distribute a task over mul- 
tiple hosts to achieve a higher through- 
put or more balanced utilization than 
centralized systems. Correctness of such 
a distributed task depends on whether 
peer processes participating in the task 
can correctly identify each other. Au- 
thentication can identify friend or foe. 

• Client-serveT interactions. The cli- 
ent-serveT model provides an attractive 
paradigm for constructing distributed 
systems. Servers arc willing to provide 
service only to authorized clients, while 
clients are interested in dealing only 
with legitimate servers. Authentication 
can be used to verify a potential con- 
sumer-supplier relationship. 

• Interdomain communication. Most 
distributed systems aTe not centrally 
owned or administered; for example, a 
campus-wide distributed system often 
interconnects individually administered 
departmental subsystems. Identifying 
principals across subsystems requires 
additional authentication mechanisms . 

In the kind of malicious environments 
postulated in our threats model, some 
basic assumptions about the system must 
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Figure 2. Distributed system configuration. 



be satisfied to achieve a reasonable lev- 
el of security. We offer a set of assump- 
tions (for other possible assumptions, 
sec Abadi et al * and Linn 5 ). Figure 2 
also depicts these assumptions. 

• Each host hardware Whas a unique 
built-in immutable identity W w and con- 
tains a tamperproof cryptographic fa- 
cility that encapsulates the public key 
k w and the private key kf of W. The 
cryptographic facility can communicate 
with the host reference monitor via a 
secure channel. Each host that supports 
user logins also has a smart card reader 
that communicates with the host refer- 
ence monitor via a secure channel. Last- 
ly, the host reference monitor has a 
secure channel to the network inter- 
face. 



• Each legitimate user U is issued a 
smart card C that has a unique built-in 
immutable identity id c . Each smart card 
C performs encryption and decryption, 
and encapsulates its private key *f 
public key for the certification authori- 
ty k A , and a pin number Pin c for its 
legitimate holder. (The pin number is 
assigned by a card-issuing procedure.) 
The channel between the smart card 
and reader is secure. Each smart card 
has its own display, keypad, and clock. 

•A physically secure centralized 
bootstrap server B maintains a data- 
base of host information. More precise- 
ly for each host H % it keeps a record 
{id H , k lh kf t i«f w . **, kf) specify-mg the 
unique hardware W that can be initial- 
ized as H. All database records can be 
encrypted under a secret master key for 
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(1) W- 

(2) B 



(4) W : 

(5) W-+ B: 

(6) B -> W: 

(7) W-» B: 

(8) B -> W: 

(9) H 



added security. B has a pub- 
lic key k 8 and a private key 

• A physically secure cen- 
tralized certification author- 
ity A maintains a database 
on ail principals. More pre- 
cisely, for each user L'. A 
keeps a record (U. id Cy k c ) % 
binding U to its smart card C. 
For each host H. A keeps a 
record (i</ H , id w ) f specifying 
tbc hardware W that H can 
run on. Also, for each server 
S % A keeps a record of its 
public key certificate (S,k s ). 
The certification authority A 
has a public key k A and a 
private key 

Each assumption is achiev- 
able with current technolo- 
gy. In particular, the technol- 
ogy of a battery-powered 
credil-card-sized smart card 
with a built-in LCD and key- 
pad that can perform special- 
ized computations has steadi- 
ly progressed. Also, many vendors 
include specialized cryptographic facil- 
ities and smart card readers for hosts as 
options. The use of a smart card or 
other forms of computational aid is es- 
sential to realizing murua) authentica- 
tion between a host and a useT. Unaided 
human users simply cannot carry out 
the intensive computations required by 
an authentication protocol. 

We assume the bootstrap server and 
certification authority are centralized. 
Decentralized servers/authorities can be 
supported by adding authentication be- 
tween them, as we discuss later. Such 
authentication can be carried out in a 
hierarchical manner as suggested in the 
protocol standard CCITT X.509. 

Although we have a certification au- 
thority in our framework, we chose to 
omit an authentication server because 
we deemed the trust level needed in a 
certification authority (which distrib- 
utes public key certificates) to be less 
than that of an authentication server. 

Secure bootstrapping. The following 
protocol is initiated when host hard- 
ware attempts a remote initialization. 
This could occur after a voluntary shut- 
down, a system crash, or a malicious 
attack by an adversary who attempts to 
penetrate the host. The secure boot- 
strap protocol allows a reinitialized host 



► all: "boot." id m [n*, id w \ kr 

: retrieve record *„. *£\ id m * H 

for W from database 
: recover n v from (/it* 

by decrypting with kj 
: generate a random key k 
: compute m = [n w , k A * k B , k\ k 
(3) B -> W; m 



recover (n^ k A% k Bf k) from m 

by decrypting with k£ 
{n w . "ready"), 
[n Wt n n .id m ik#) km .OS) t 

[id„ id w , *„, T\ k j 
validate certificate {uf w , id m k tl 
by encrypting with k M 



Figures 3. Secure bootstrap protocol. 



to attain a "safe" state prior to resuming 
normal operation. In particular, a cor- 
rectly loaded reference monitor is ready 
to assume control of the host in this 
state. 

Suppose that the hosts and the boot- 
strap server B arc on the same broad- 
cast network, allowing the message in 
step 1 of Figure 3 to be received by B. 
In that protocol. n w and n B are nonces, 
A' is a session key, OS is a copy of the 
operating system, and T is a time 
stamp. 

In step 1. W announces its intention 
to reboot by broadcasting a boot re- 
quest. Only B (which has knowledge of 
k w ] ) can recover the nonce n w . In step 2, 
B generates a fresh key k to be used for 
loading OS. In step 4, W ascertains that 
in is not a replay by checking the com- 
ponent n Wt since only B could have com- 
posed message m. Thus k A% k B> and k in 
m can be safely taken lo be the public 
key of certification authority A, the 
public key of B, and the session key to 
be used for loading OS. At this point, B 
has been authenticated by W. 

When the message "ready" encrypt- 
ed with k is received in step 5, B is 
certain that the original boot request 
actually came from IV, since only W can 
decrypt m to retrieve k. Hence, B and W 
have mutually authenticated each 
other. 



Step 6 is the actual loading 
of OS and the transferring of 
host /Ts private key /c/j 1 . OS 
includes its checksum, which 
should be recomputed by W 
to delect any OS tampering 
in transit. W acknowledges 
receipt of ktf and OS by re- 
turning the nonce n B signed 
with k u l . B verifies that the 
correct n B is returned. Then 
in step 8, a license signed by 
B affirming the binding of 
host id H with public key k H 
and hardware id w is sent to 
W. After receiving the license. 
W officially -becomes" H, 
which retains this license as 
proof of successful bootstrap- 
ping and of its own identity. 
The time stamp field 7' with- 
in the license denotes its ex- 
piration date. 

If its secrecy is not required, 
OS can be transferred unen- 
crypted. However, the check- 
sum of OS must be sent in 
encrypted form. 



User-host authentication. This func- 
tion occurs when user U walks up to 
host H and attempts to log in. The au- 
thentication requires smart card C. A 
successful authentication guarantees 
host H that U is the legitimate holder of 
C and guarantees user U that it is a 
"safe" host to use. The host is safe if it 
holds a valid license (which may have 
been obtained through secure bootstrap- 
ping) and possesses knowledge of the 
private key k„ l . 

In most systems, the end result of a 
successful user authentication is the cre- 
ation of a login process by the host's 
reference monitor on the user's behalf. 
The login process is a proxy for the user, 
and all requests generated by this pro- 
cess are taken as if they are directly 
made by the user. However, a remote 
host/server has no way of confirming 
such proxy status, except to trust the 
authentication capability and integrity 
of the local host. Such trust is unaccept- 
able in a potentially malicious environ- 
ment because a compromised host can 
simply claim the existence of user login 
processes to obtain unauthorized sex- 
vices. 

This trust requirement can be al- 
leviated if a user explicitly delegates 
authority to the login host." The del- 
egation is carried out by having the 
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(1) C^H: 

(2) H -> A: 

(3) A 

(4) A -» H: 

(5) // 



(6) H-» 

(7) C 

(8) V 

(10) C 



(11) C -» tf 

(12) H 



user's smart card sign a login 
certificate to the login host 
upon the successful termi- 
nation of a user-host au- 
thentication protocol. The 
login certificate asserts the 
host's proxy status with re- 
spect to the user and can be 
presented by the host in 
future authentication ex- 
changes. 

Because forgery can occur, 
the possession of a login cer- 
tificate should not be taken 
as sufficient proof of delega- 
tion. The host also must dem- 
onstrate the knowledge of a 
private delegation key k; 1 
whose public component k 4 
is named in the certificate. 
Also, to reduce the potential 
impact of a host compromise, 
the login certificate is given 
only a finite lifetime by in- 
cluding an expiration time 
stamp. 

We present such a user- 
host authentication protocol 
in Figure 4. We assume that the host 
holds a valid license \id H , id Wt k M> T)*-i, 
as would be the case if the host has 
executed the secure bootstrap protocol. 
In the figure, n c is a nonce, k 4 is the 
public delegation key whose private 
counterpart k? is kept secret by the 
host, and T t is a time stamp denoting 
the expiration dale of the login certifi- 
cate. 

A user inserts his/heT smart caTd into 
the host's card reader. The card's iden- 
tity id c and a nonce n c are sent through 
the card reader to the host in step 1. In 
step 2, H requests user information as- 
sociated with id c from certification au- 
thority A. Since the license held by H 
was signed by B and hence is not deci- 
pherable by C, a key translation is re- 
quested by H in the same step. (Note 
that these licenses can be cached by H 
and need not be requested for every 
user authentication.) After receiving a 
reply from A in step 4, H knows both the 
legitimate holder U of the card C and 
the public key k c associated with the 
smart card. Knowledge of can be used 
to enforce the local discretionary con- 
trol to provide service (or not), while k c 
is needed to verify the authenticity of C. 
In step 5, // generates a new delegation 
key pair (*„, *;'). H keeps fc; 1 private, to 
be used as proof of a successful delega- 
tion from V to H. 



id c , "e 

id c , I'd* id m k» T] k j 
check time stamp of certificate 
if time stamp expired, abort 
[id* uf w * M T) k f. \U, id Ct fcc|«* 
generate new delegation key pair 

(id* id w kf,, rj ti ., k 4t n c |* ; i 
iVf M . id w 



: verify if id H lid w is the desired host 
: if not, abort 
C: Pin 
: verify Pin = Pin c 
: if not equal, abort 
[V, id* k„ T.\ k , 

verify correct delegation by decrypting 
the login certificate id^ k 4l T t \ k + 
with k c 



Figure 4. User-host authentication protocol. 



In step 6, H returns the nonce n c with 
the public delegation key k< and a copy 
of its license to C. In step 7, C retrieves 
(id Jh id w ), the identity of H, from the 
license by decrypting it with k A . A check 
ensures that the time stamp in the li- 
cense has not expired. The identity (id K , 
idy) is then displayed on the card's own 
screen. To proceed, the user enters the 
assigned pin number on the card's key- 
pad. In step 10, the pin number is com- 
pared with the one stored in the card. If 
they are equal, C signs a login certifi- 
cate binding the user V with the host id H 
and the public delegation key k 4 . This is 
sent to H in step 11. The host (and 
others) can verify the validity of the 
login certificate using fc 0 the card's pub- 
lic key. 

When user V logs out, the host erases 
its copy of the private delegation key k} 1 
to void the delegation from U. If H is 
compromised after the delegation, the 
effect of the login certificate is limited 
by its lifetime, 7V 

Peer-peer authentication. This type 
of mutual authentication and crypto- 
graphic parameters negotiation is per- 
formed in the connection-establishment 
phase of a secure connection-oriented 
protocol. 

The protocol in Figure 5 mutually 
authenticates peers P and Q, and estab- 



lishes a new session key for 
their future communication 
(n, and n Q are nonces, while 
k is a fresh session key). 

In step 1 , P informs A of its 
intention to establish a se- 
cure connection with Q. In 
step 2, A returns to P a copy 
of Q's public key certificate. 
In step 3, P informs Q of its 
desire to communicate, and 
sends a nonce In step 4, Q 
asks A for F's public key cer- 
tificate and requests a ses- 
sion key at the same time. In 
order for Q to subsequently 
prove to P that the session 
key k is actually from A (not 
Q's own creation), A sends a 
signed statement containing 
the key k t and C's name. 
This basically says that k is a 
key generated by / on behalf 
of G's request identified by 
The binding of k and n f 
assures P that k is fresh. In 
step 6, A % * signed copy of 
(fl* *, (?) « relayed to P to- 
gether with a nonce n Q generated by Q. 
P's knowledge of the new session key k 
is indicated to Q by the receipt of n Q in 
step 7. 

Client-server authentication. Since 
both clients and servers are implement- 
ed as processes, the basic protocol for 
peer-peer authentication can be applied 
here as well. However, several issues 
peculiar to client-server interactions 
need to be addressed. 

In a general-purpose distributed com- 
puting environment, new services (hence 
servers) are made available dynamical- 
ly. Thus, instead of informing clients of 
every service available, most implemen- 



(1) P -> A : P,Q 

(2) A Pi \Q. k 0 ) k} * 

(3) F ->G: \n»PU 0 

(4) Q-> A: Q, P, {n,U, 

(5) A Q: \P, Mi,- 
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Figure 5. Peer-peer authentication 
protocol. 
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U->H : 
H -> Kerberos: 
Kcrbcros 



Kcrbcros -> H\ 
H->U 
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laiions use a service broker 
to keep track of and direct 
clients to appropriate provid- 
ers. A client first contacts the 
service broker by using a pur- 
chase protocol that performs 
the necessary mutual authen- 
tication prior to the granting 
of a ticket. The client later 
uses the ticket to redeem ser- 
vices from the actual server 
by using a redemption pro- 
tocol. 

Authentication performed 
by the purchase protocol pro- 
ceeds the same way as the 
protocol for peer-to-peer 
authentication, while in the 
redemption protocol authen- 
tication is based upon pos- 
session of a ticket and knowl- 
edge of some information 
recorded in the ticket. Such a ticket 
contains the names of the client and 
server, a key, and a time stamp to indi- 
cate lifetime (similar to a login certifi- 
cate). A ticket can be used only be- 
tween the specified client and server, A 
prime example of this approach is the 
KerbeTOS authentication system, which 
we later discuss. 

Another special issue of clieni-servcr 
authentication is proxy authentication. 1 
To satisfy' a client's request, a server 
often needs lo access other servers on 
behalf of the client. For example, a da- 
tabase server, upon accepting a query 
from a client, may need to access the file 
server to retrieve certain information 
on the client's behalf. A straightfor- 
ward solution would require the file 
server to directly authenticate the cli- 
ent. However, this may not be feasible. 
In a long chain of service requests, the 
client may not be aware of a request 
made by a server in the chain and hence 
may not be in a position to perform the 
required authentication. An alternative 
is to extend the concept of delegation 
previously used in user-host authenti- 
cation. 7 A client can forward a signed 
delegation certificate affirming the del- 
egation of its rights to a server along 
with its service request. The server is 
allowed lo delegate to another server 
by signing its own delegation certificate 
as well as by relaying the client's certif- 
icate. In general, for a service request 
involving a sequence of servers, delega- 
tion can be propagated to the final serv- 
er through intermediate ones, forming 
a delegation chain. 



U 

U,TGS 

retrieve k v and k^ from database 
generate a new session key k 
create ticket-granting ticket 

tick rGS =\U*TGS<k,T.L\ ku9 
\TGS.k, r.L. dcknJ^ 
"Password?" 
passwd 

compute I = f {passwd) 
recover fc, iick TCS by decrypting 
(TCS, Ic, 7\ t, cfe* m ] c with / 
if decryption fails, abort login 
otherwise retain tick TGi and k 
erase passwd from memory 



ning all domains can be used 
to provide globally unique 
names lo principals. A good 
example of this is the Do- 
main Name System used in 
Interncif 

Trust refers to the willing- 
ness of a local certification 
authority to accept a certifi- 
cation made by a remote au- 
thority regarding a remote 
principal. Such trust relation- 
ships must be explicitly es- 
tablished between domains, 
which can be achieved by 



Figure 6. Kerberos credential -initialization protocol. 



Various refinements can extend the 
scheme. A form of restricted delegation 
can be carried out by explicitly specify- 
ing a set of rights and/or objects in a 
delegation certificate. 

Interdomain authentication. We have 
assumed a centralized certification au- 
thority uusted by ail principals. How- 
ever, a realistic distributed system is 
often composed of subsystems indepen- 
dently administered by different author- 
ities. We use the term domain to refer to 
such a subsystem. Each domain D main- 
tains its own certification authority A D 
that has jurisdiction over all principals 
within the domain. Intradomuin authen- 
tication refers to an exchange between 
two principals belonging to the same 
domain, whereas inHtrdomam authenti- 
cation re fen lo an exchange that in- 
volves two principals belonging to dif- 
ferent domains. 

Using the previously described pro- 
tocols, A n is sufficient for all intrado- 
main authentications for each domain 
O. However, a certification authority 
has noway of verifying a request from a 
remote principal, even if the request is 
certified by a remote certification au- 
thority. Hence, additional mechanisms 
are required for interdomain authenti- 
cation. 

To allow this type of authentication, 
two issues need to be addressed: nam- 
ing and irusi. Naming ensures that prin- 
cipals are uniquely identifiable across 
domains, so that each authentication 
request can be attributed to a unique 
principal. A global naming system span- 



• sharing an interdomain key 
between certification au- 
thorities that are willing to 
trust each other, 

• installing the public keys of 
all trusted remote authori- 
ties in a local certification authori- 
ty's database, and 

• introducing an interdomain author- 
ity for authenticating domain-level 
authorities. 

A hierarchical organization corre- 
sponding to that of the naming system 
can generally be imposed on the certifi- 
cation authorities. In this case, an au- 
thentication exchange between two 
principals f* and Q involves multiple 
certification authorities on a path in 
the hierarchical organization between 
P and Q? The path is referred to as a 
certification path. 

Case studies 

We study two authentication servic- 
es: KeTberos and SPX. Both address 
client-server authentication needs. Their 
services are generally available lo an 
application program through a program- 
ming interface. While Kerberos uses a 
symmetric crypt osystem, SPX uses an 
asymmetric cryplosystem as well. 

Kerberos. This system was designed 
for Project Athena at the Massachu- 
setts Institute of Technology.' The 
project goal is to create an educational 
computing environment based on high- 
performance workstations, high-speed 
networking, and servers of various types. 
Researchers envisioned a large-scale 
(10.000 workstations to 1,000 servers) 
open-network computing environment 
in which individual workstations can be 
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privately owned and operated. There- 
fore, a workstation cannot be trusted to 
identify its users correctly to network 
services. Kerberos is not a complete 
authentication framework required for 
secure distributed computing in gener- 
al; it only addresses issues of client- 
server interactions. 

We limit our discussion to the Ker- 
beros authentication protocols and omit 
various administrative issues. 

The design is based on using a sym- 
metric cryptosystem with trusted third- 
party authentication servers. It is a re- 
finement of ideas presented in Needham 
and Schroedei.' The basic components 
include Kerberos authentication and 
ticket-granting servers (TGSs). A data- 
base contains information on each prin- 
cipal It stores a copy of each principal's 
key that is shared with Kerberos. For a 
user principal V, its shared key k v is 
computed from its password password^ 
specifically, k v ^ f(passwofd v ) for some 
one-way function /. Kerberos servers 
and TGSs read the da tab ase in the course 
of authentication. 

Kerberos uses two main protocols. 
The credential- initialization protocol 
authenticates user logins and installs 
initial tickets at the login host. A client 
uses the client-server authentication 
protocol to request services from a 
server. 

The credential-initialization protocol 
uses Kerberos servers. Let V be a user 
who attempts to log into host H, and / 
be the one-way function foT computing 
k v from ITs password. The protocol is 
specified in Figure 6 (here, Kerberos 
refers to the server): 

If posswdh not the valid password of 
17, / would not be identical to k v , and 
decryption in the last step would fail. 
(In practice,/ may not be one-to-one. It 
suffices to require that given two dis- 
tinct elements x and y, the probability 
of /(*) being equal to/(y) is negligible.) 
Upon successful authentication, the host 
obtains a new session key k and a copy 
of the ticket-granting ticket 

tick lvs ={U t 7C5,ic,r,q 4ni ,, 

where T is a time stamp and L is the 
ticket's lifetime. The ticket-granting tick- 
et is used to request server tickets from 
a TGS; note that tick^, is encrypted 
with fcrc. ibe shared key between TGS 
and Kerberos. 

Because a ticket is susceptible to in- 
terception or copying, it does not con- 



(1) C -* TGS: 5, tick^, [Q T,) k 


(2) TGS 


recover k from tick^ by decrypting with k^ 




recover T, from (C, T x ) k by decrypting with k 




check timeliness of 7, with respect to local clock 




create server ticket ffcfcj = {C, S, *\ 7\ L\ 


(3) TGS C: 


[S,kr t T.L%tick s \ k 


<4)C : 


recover k' t tick s by decrypting with k 


(5)C-*S : 


tick s AC t T 2 } h . 


(6) 5 


recover Jf from tick s by decrypting with k s 




recover T 2 from (C, T 2 ] r by decrypting with kf 




check timeliness of T 2 with respect to local clock 


(1)S-*C : 





Figure 7. Kerberos dieot-server authentication protocol. 



stitute sufficient proof of identity. 
Therefore, a principal presenting a tick- 
et must also demonstrate knowledge of 
the session key I: named in the ticket. 
An autbenticator (to be described) pro- 
vides the demonstration. Figure 7 shows 
the protocol for client C to request 
network service from server S (T, and 
T x are time stamps). 

In step 1, client C presents its ticket- 
granting ticket tick's to TGS to re- 
quest a ticket for server 5. (Note that 
each client process associates with the 
unique user who created the process. It 
inherits the user ID and the ticket- 
granting ticket issued to the user dur- 
ing login.) Cs knowledge of k is dem- 
onstrated using the autbenticator 
|C,r,) 4 . In step 2, TGS decrypts tick TCS , 
recovers fc, and uses it to verify the 
autbenticator. If both step 2 decryp- 
tions are successful and 7\ is timely, 
TGS creates a ticket tick s for server 5 
and returns it to C Holding tick, t C 
repeats the authentication sequence 
with 5. Thus, in step 5, C presents 5 
with tick s and a new autbenticator. In 
step 6, 5 performs verifications similar 
to those performed by TGS in step 2. 
Finally, step 7 assures Cof the server's 
identity. Note that this protocol requires 
"loosely synchronized" local clocks for 
the verification of time stamps. 

Kerberos can also be used for au- 
thentication across administrative or 
organizational domains. Each domain 
is called a realm. Each user belongs to 
a realm identified by a field in the us- 
er's ID. Services registered in a realm 
will accept only tickets issued by an 



authentication server for that realm. 

An inter re aim key supports cross- 
realm authentication. The TGS of one 
realm can be registered as a principal in 
another by using the shared inter realm 
key. A user can thus obtain a ticket- 
granting ticket for contacting a remote 
TGS from its local TGS. When the tick- 
et-granting ticket is presented to the 
remote TGS, it can be decrypted by the 
remote TGS, which uses the appropri- 
ate intenealm key to ascertain that the 
ticket was issued by the user's local 
TGS. An authentication path spanning 
multiple intermediate realms is possi- 
ble. 

Kerberos is an evolving system on its 
fifth version. Bellovin and Merrill" dis- 
cuss limitations of previous versions, 
some of which have been remedied. 

SPX. This authentication service is 
also intended for open-network envi- 
ronments." SPX is a major component 
of the Digital Distributed System Secu- 
rity Architecture* and its functionalities 
resemble those of Kerberos. It has cre- 
dential-initialization and client-server 
authentication protocols. In addition, it 
has an enrollment protocol that regis- 
ters new principals. We focus on the 
first two protocols and omit the last, 
along with most other administrative 
issues. 

SPX has a Login Enrollment Agent 
Facility (LEAF) and a Certificate Dis- 
tribution Center (CDC) that corre- 
sponds to Kerberos servers and TGSs. 
LEAF, similar to a Kerberos server, is 
used in the credential-initialization pro- 
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(1) U->H 


: {/, passwd 


(2)//->LEAF 




(3) LEAF -> CDC: U 


(A) CDC -* LEAF: (|*J , } Mpw ^ h^assword^ [k\ k%M 


(5) LEAF 


: recover Jtc by decrypiing with 




: recover \k^\ k ^ uwefttv% and /^(p/wjuWy) by 




decrypting with k 




: verify h x {passwd) ^ h^ipaisword^) 




: if not equal, abort 


(6)LEAF->W 




(1)H 


: recover kf by decrypting first with n and then with 




h 7 (j?asswd) 




: generate (RS A) delegation key pair (k d , k?) 




: create ticket tick u = \L % V, fcj^ 


(8)//->CDC 


: t; 


(9) CDC -> i* 


: 



Figure 8. STX credential-initialization protocol. 



tocol. CDC is an on-line depository con- 
sisting of public key certificates (for 
principals and certification authorities) 
and the encrypted private keys of prin- 
cipals. Note that CDC need not be trust- 
worthy because everything stored in it 
is encrypted and can be verified inde- 
pendently by principals. 

SPX also contains hierarchically or- 
ganized certification authorities (CAs), 
which operate offline and are selective- 
ly trusted by principals. Their function 
is to issue public key certificates (bind- 
ing names and public keys of princi- 
pals). Global trust is not needed in SPX. 
Each CA typically has jurisdiction over 
just one subset of all principals, while 
each principal P (rusts only a subset of 
all CAs, referred to as the trusted au- 
thorities of P. System scalability is greatly 
enhanced by the absence of global trust 
and on-line trusted components. 

'Itie credential-initialization protocol 
is performed when a user logs in (see 
Figure 8). It installs a ticket and a set of 
trusted-authority certificates for the user 
upon successful login. In the protocol, 
t/is a user who attempts to log in to host 
H\pmswd\% the password entered by U; 
7 is a time stamp: L is the lifetime of a 
ticket; n is a nonce; h } and h 2 are publicly 
known one-way functions; k is a (DES) 
session key; k v% A LEAF , k A are respective- 
ly the public keys of U, the LEAF serv. 
cr, and a trusted authority A of U; and 



ktf and k'^ At . are respectively the pri- 
vate keys of U and LEAF. 

In step 1, user U enters its ID and 
password. In step 2, H applies the one- 
way function h t to the password V en- 
tered and sends the result, along with a 
time stamp T and a nonce n f in a mes- 
sage to LEAF. Upon receiving the mes- 
sage from H, LEAF forwards a request 
to CDC for U's private key. This key is 
stored as a record ( I* J 1 
h password v )) in CDC. Note that a 
compromise of CDC would not reveal 
these private keys. In step 4, CDC sends 
the requested private-key record to 
LEAF using a temporary session key k. 
In step 5, LEAF recovers both 
I^J'L^om^m and h x {pas!word a ) from 
CDC's reply. LEAF then verifies 
passwd by checking h t {passwd) against 
h x {passwordJ)Ai they are not equal, the 
login session is aborted and the abor- 
tion logged. Because h^assword^ is 
not revealed to any principal except 
LEAF, password-guessing attacks would 
require contacting LEAF for each guess 
or compromising LEAFs private key. 

Having determined the password to 
be valid, LEAF sends the first part of 
the private-key record encrypted by n 
to H in step 6. (The nonce n sent in step 
2 is used as a symmetric key for encryp- 
tion.) In step 7, It recovers k$ by de- 
crypting the reply from LEAF first with 
n and then with h 2 (passwd). H then gen- 



erates a pair of delegation keys and 
creates a ticket fi'cJc f » In step 8, H re- 
quests the public key certificate for a 
trusted authority of U from CDC. CDC 
replies with the certificate in step 9. In 
fact, multiple certificates can be ret urned 
in step 9 if V trusts more than one CA. 
These trusted authorities' certificates 
. were previously deposited in the CDC 
by U using the enrollment protocol. 

The authentication-exchange proto- 
col between a client C and a server S 
follows. To simplify the protocol speci- 
fication so that a single public key cer- 
tificate is sent in step 2 and in step 5. we 
made the following assumption: Let Cs 
public key certificate be signed by A c 
where A c denotes a trusted authority of 
5. Similarly, let Ts public key certificate 
he signed by A s where A s denotes a 
trusted authority of C. Below. T is a 
time stamp, and Ac is a (DES) session 
key: 

(1)C-*CDC: 5 
<2)CDC->C: (5.*,)^ 
(3)C->5 : T,\k\ k ,iick c ,\k?U 
(A) S -> CDC : C 

(5) CDC->S: !C* C )^ 

(6) S : validate tic.k L by 
encrypting with k t 

(7) 5-»C : ir+lf. 

In step t. C requests 5*s public key 
certificate from CDC. In step 2, CDC 
returns the requested certificate. C can 
verify the public key certificate by de- 
crypting it with k Ajl , which is the public 
key of A s obtained by C when it execut- 
ed the credential-initialization proto- 
col. In step 3, iick c and the private del- 
egation key k} x generated in step 7 of 
the credential-initialization protocol, as 
well as a new session key Jr, are sent to 
5. Only 5 can recover k from \k\ kt and 
subsequently decrypt \kj\ k to recover 
k 4 \ Possession of Uck c and knowledge 
of the private delegation key constitute 
sufficient proof of delegation from Cto 
S. However, if such delegation from C 
to 5 is not needed. 



ll*U,j> 

is sent in step 3 instead of this 
acts as an authenticator for proving 
Cs knowledge of k'J without revealing 
it. In steps 4 and 5, 5 requests the 
public key certificate of C, which is 
used to verify tick c in step 6. In step 7, S 
returns |7+ l) t to Cto complete mu- 
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tual authentication between C and S. 

Since SPX is a relatively recent pro- 
posal, its security properties have not 
been studied extensively. Such study 
would be necessary before it could be 
generally adopted. 

Although SPX offers services similar 
to those of Kerberos, its elimination of 
on-line trusted authentication servers 
and the extensive use of hierarchical 
trust relationships are intended to make 
SPX scalable for very large distributed 
systems. 



Most of the protocols we present are 
practically feasible, and their adop- 
tion and use should be just a matter of 
need. 

The complexity of understanding and 
managing the security of a distributed 
system requires a formal approach that 
allows precise specifications of both the 
system's architecture and its protocols. 
Lam, Shankar, and Woo" have pro- 
posed a basis for developing such an 
approach. ■ 



With the growth in scale of dis- 
tributed systems, security has 
become a major concern — 
and a limiting factor — in their design. 
Security has been strongly advocated as 
one of the major design constraints in 
both the Athena project at the Massa- 
chusetts Institute of Technology and 
the Andrew project at Carnegie Mellon 
University. Most existing distributed sys- 
tems, however, do not have a well- 
defined security framework and use au- 
thentication only for their most critical 
applications, if at alL 
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Abstract. We present a related family of authentication and digital sig- 
nature protocols based on symmetric cryptographic primitives which per- 
form substantially better than previous constructions. Previously, one- 
time digital signatures based on hash functions involved hundreds of hash 
function computations for each signature; we show that given online ac- 
cess to a timestamping service, we can sign messages using only two 
computations of a hash function. Previously, techniques to sign infinite 
streams involved one such one-time signature for each message block; 
we show that in many realistic scenarios a small number of hash func- 
tion computations is sufficient. Previously, the Diffie Hellman protocol 
enabled two principals to create a confidentiality key from scratch: we 
provide an equivalent protocol for integrity, which enables two people 
who do not share a secret to set up a securely serialised channel into 
which attackers cannot subsequently intrude. In addition to being of po- 
tential use in real applications, our constructions also raise interesting 
questions about the definition of a digital signature, and the relationship 
between integrity and authenticity. 

Keywords: authentication, non-repudiation, hashing, timestamping 

1 Introduction 

Most existing cryptographic protocols that provide non-repudiation, whether of 
origin or receipt, are based on digital signature algorithms such as RSA and 
DSA. However convenient this may be in some applications, is not necessary: 
nonrepudiation services have been provided without signatures, and an example 
is the SWIFT system for international banking transactions that was fielded in 
the mid 1970 's as a replacement for older and less secure telegraphic transfer 
systems. In SWIFT, pairs of corresponding banks shared MAC keys that were 
exchanged manually; the messages passed from one bank to another over a pri- 
vate network with multiple independently administered logging facilities (the 
latest version of SWIFT has digital signatures but since they are apparently 
applied to the MAC, the logging service is still needed for non-repudiation). 
However third party logging facilities are expensive and in many applications it 



is desired that principals should have the means to generate and store evidence 
that they might need to press their claims in subsequent disputes. 

An early system that did not rely on third party logging was designed by 
TRW for the NSA in the 1970's to authenticate messages from sensors placed in 
missile silos to monitor the SALT 2 treaty [1]. It used concatenated encryption: 
a message would first be encrypted using a Russian device and then with an 
American one. The keys were made available to the other side (and to third 
party monitors such as the United Nations) after the messages had been logged 
by all interested parties. This technique was published in 1983 in the context of 
the test ban treaty; at that time, it was preferred over RSA because neither of 
the two superpowers would trust a device built by the other, and asymmetric 
mechanisms were felt to offer little additional benefit given this constraint [2]. 

The first published approach to the provision of nonrepudiation without using 
asymmetric encryption is due to Lamgp^J, who generates signatures by opening 
commitments that have been made using a one-way hash function [3]. The basic 
idea here is that the signer chooses two random numbers (representing 0 and 1) 
for each bit of the message, and publishes their images under a one-way hash 
function. To sign a message, he reveals the preimages corresponding to the actual 
O's and I's. Despite refinement by Merkle [4,?], by Even, Goldreich and Micali 
[6] and by Bleichenbacher and Maurer [7], this technique still requires a lot of 
hash computations. 

In this paper, we show how to construct digital signatures that require only a 
small number of hash function computations each. This enormous improvement 
is brought about by making signature interactive; users may either interact with 
each other or with a time-stamping service. In many applications, interaction 
with a counterparty or a trusted third party service is a requirement in order to 
verify the availability of funds, the uniqueness of negotiable instruments or the 
absence of a key on a certificate revocation list. In this case, it may be possible 
to dispense with signatures based on number theory. 

Possible benefits include the elimination of some patent royalty and export 
control problems and a measure of insurance against any success that quan- 
tum computers have in breaking systems based on number theory. In addition, 
as there are no long term secrets in our protocols, they might help to over- 
come intelligence agency concerns that signature keys can easily be abused for 
encryption. Finally, our constructions raise a number of interesting theoretical 
points. 

2 The Basic Idea 

The underlying idea came to us on the 4th November 1996 while discussing how 
a modern day Guy Fawkes, about to blow up the Houses of Parliament, could 
arrange publicity for his cause — but without getting caught 1 . 

1 for the benefit of readers unfamiliar with British history, Fawkes conspired to blow 
up King James the first and the Houses of Parliament in 1605; this was an attempt 
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The naive approach might be to telephone the newsroom of the 'Times' and 
say "I represent the free Jacobin army and we are going to carry out a liberation 
action tomorrow. Once we have done it, I will call using the code word { Darnley' 
to state our demands". 

2.1 Using hash functions 

This is not a particularly secure way of doing things. The message will be passed 
on to the police, who might remember that the state opening of Parliament is 
imminent and double the guard. So it would be more prudent to send a hash 
of the message. Provided that the hash function is truly one-way (technically, 
pseudorandom), this will not leak information. If Fawkes is now successful, he 
can reveal the message and find himself possessed of a very credible codeword. 

We understand that organisations such as the IRA do in fact share codewords 
with newspapers and use these to claim credit for their crimes. However, such 
a protocol is open to abuse by newspaper staff (as well as by other people 
with access, such as phone company employees and policemen authorised to tap 
telephone lines). So our next logic step in improving the protocol is to replace 
the codeword with its hash. 

Our protocol is now 

- Select a random codeword X 

- Form its hash Y = h{X) 

- Construct a message M — "We are the free Jacobin army and we are going 
to blow up the Houses of Parliament tomorrow. The codeword by which we 
will authenticate ourselves afterwards will be the preimage ofY" 

- Compute Z = h(M) and publish it anonymously 

- Blow up the Houses of Parliament 

- Reveal M. 

This might appear to be only a slightly more technological version of the 
protocols already used by various liberation groups and criminals. It still suffers 
from the serious problem that, in the face of a capable motivated opponent, the 
password is only one-time; once it has been revealed, and is known to the news- 
papers and the police, any journalist or policeman could in theory masquerade as 
the rebel leader. Indeed, if Guy Fawkes tries to state his demand by sending the 
Times' the codeword X with a political demand P (Votes for Catholics!'), the 
police can intercept the message and replace P with the demand P' ('a million 
guineas for Fawkes!'), thus discrediting Fawkes and his organisation. 

to end the persecution of Roman Catholics. Fawkes was caught as a result of a 
comsec failure (a coded letter from one of the conspirators was intercepted and 
deciphered). After his public execution, Parliament ordained the 5th of November 
as a day of thanksgiving for their narrow escape, and it is still celebrated by bonfires 
and fireworks displays. 
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2.2 The Guy Fawkes Protocol 

Our critical innovation is to introduce a chaining mechanism that lets us bind 
codewords to messages in a way that provides not just authentication but also 
nonrepudiation. It also allows the secret codeword to be refreshed, so that the 
system can be used an arbitrary number of times. 

The basic idea is that, at each round of the protocol, we firstly commit to a 
string consisting of (codeword, message, [hash of next codeword]) by publishing a 
hash of it. This commitment binds the message to the codeword and its successor. 
We then reveal the value of this string, proving our knowledge of the codeword 
and thus authenticating ourselves. 

Formally, we define the protocol by induction. Suppose that we have pub- 
lished Zi followed by the message Mi containing h(Xi), where our secret code- 
word is currently X{. We wish to authenticate the message M<+i. We follow the 
following protocol: 

- Select a random codeword Xi+i 

- Form its hash h(Xi+i) 

- Compute Zi+i = fc(Mi+i, h(X i+ i),Xi) and publish it 

- Reveal Mi+i,h(Xi+i) and X { 

The first codeword needs to be bootstrapped by some external mechanism; 
in most applications, this would be a conventional digital signature or an out- 
of-band authentication, perhaps using a conventional CA. We will give some 
examples below. 

3 Discussion 

Hash chains were introduced by Lamport [3] and have been used in one-time 
password applications such as the S/Key one-time password system [8], as well 
as several electronic payment protocols [9-11]. There, as here, the effect is to 
establish secure association at low computational cost. 

In S/Key, a user has a series of one-time passwords, each of which is the 
preimage of its predecessor; the goal is to show that an authorised user is present 
and protect against passive attacks (though not against active attacks such as 
session stealing) . This chain of events is rooted in a single manual authentication 
event in which the last element of the hash chain is set as the first password in 
the system. 

In the payment protocols, the goal is to associate a number of electronic 
coins with a single digital signature that authenticates them all, and thus enable 
a series of small payments to be made by a customer to a single merchant 
(such as a phone company) at the cost of a single digital signature or online 
authentication operation. 
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In the Guy Fawkes protocol, the objective is to associate a single act of 
authentication with a stream of future statements rather than a stream of future 
events. Functionally, the difference is that while the format of all the digital 
coins is known at the time they are signed, the future statements that we wish 
to authenticate may not be. So it would not be sufficient to simply use a hash 
chain (as in S/Key) as a set of one-time passwords for authenticating political 
statements. As in section 2.1 above, anyone who was tapping the line when the 
statement and password were sent to the newsroom could alter the statement; 
and staff in the newsroom could also substitute messages at will. 

In other words, the broadcast commitment step has the criticial effect of 
providing nonrepudiation, and gives the Guy Fawkes protocol the same effect as a 
digital signature. Were the Jacobins permitted to use asymmetric cryptography, 
then their first message could just as well have read "We are going to blow up 
the Houses of Parliament on the 5th November. Future demands will be digitally 
signed and the public verification key is W '.* This could have been encrypted 
and published, with the key made known after the event. 

So we might ask whether there is anything to signature other than secure 
association. After all, in the conventional model, a digital signature sets up a 
secure association between something that has been signed at an arbitrary time, 
and an authentication instance which may have involved showing a passport to 
a certification authority. Is the Guy Fawkes protocol any different? 

4 It may be secure, but it is a signature? 

At this point, some might argue that although the Guy Fawkes protocol gives 
the same effect as a digital signature, it is not actually a signature. However, 
our protocol satisfies most of the definitions of 'digital signature' offered in the 
literature to date. We will go through them in turn. 

Diffie and Hellman introduced the concept of digital signature in their sem- 
inal 'New Directions' paper: l it must be easy for anyone to recognise the 
signature as authentic but impossible for anyone other than the legitimate 
signer to produce if [12]. At the time when this paper was written, the only 
known way of doing this was using Lamport's one-time signature. The Guy 
Fawkes protocol improves on Lamport and so, not surprisingly, satisfies this 
definition; it also satisfies a later definition by Diffie as l a way of demon- 
strating to other people that (a message) had come from a particular person 1 
[13]. 

Fiat and Shamir refine and extend the definition given by Diffie and Hellman. 
Authentication is when A can prove to B that she's A, but no-one else can 
prove to B that he's A; identification is when A can prove to B that she's 
A, but B cannot prove to anyone else that he's A; and signature is when A 
can prove to B that she's A, but B can't even prove to himself that he's A 
[14]. Guy Fawkes satisfies this definition too. 
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Goldwasser, Micali and Rivest give a more involved description that explic- 
itly mentions a number of algorithms and their properties: a key generation 
algorithm, a signature algorithm, and a verification algorithm. The signa- 
ture algorithm produces a signature on being input the message, the key 
and possibly other information (such as a random input); however, in their 
definition it produces only a single output [15]. 

This model therefore excludes the Guy Fawkes protocol. But it also excludes 
the large class of arbitrated signatures that were already well known and 
in use by that time (see, for example, [16]) as well as most of the special 
purpose signature constructions that require interaction, such as undeniable 
signatures, designated confirmer signatures and oblivious signatures [17]. 

Naor and Yung refined the approach of Goldwasser, Micali and Rivest, by 
cutting the complexity theoretic requirement of the construction [18] ; it was 
finally reduced by Rompel to the existence of one-way functions (which is 
minimal) [19]. However, like Goldwasser, Micali and Rivest, their definitions 
also fail to deal with signatures that use interaction. 

Pfitzmann provides the most thorough study of disparate signature schemes 
in her thesis [20]. She concludes that the general definition of signature is 
a process with a number of access points — typically for the signer, the 
recipient and the court. Time is a necessary component, although logical 
time (in the sense of a 'global notion of numbered rounds') is sufficient 
(op. cit, p 54). Special access points can be added for risk bearers such as 
certification and revocation authorities. This definition clearly admits the 
Guy Fawkes protocol. 



So if it is claimed that the Guy Fawkes protocol is not really a signature, then 
the onus would be on the objector to show how to deal with the many other 
kinds of signature that use interaction, as well as the importance of context 
— the framework of certification and revocation services, legal conventions and 
so on — to the utility of digital signatures. In most applications, the value of 
signatures ultimately depends on convention (such as a digital signature law, 
or a contract between members of an EDI system) and the validation of even 
conventional digital signatures involves reference to an online or at least near- 
real-time certificate revocation list. 

In passing, we observe that the signatures produced by Guy Fawkes are ac- 
tually stronger than RSA in the sense that they can be fail-stop at no extra cost: 
just choose the secrets Xi uniformly at random as bitstrings significantly longer 
than the hash function's output. That way, an attacker who finds a preimage 
of a commitment or hashed codeword will with high probability have found a 
different one from that known to the genuine signer, who will thus be able to 
exhibit a collision for the hash function. 
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5 Signing Bidirectional Digital Streams 



Hash-based signatures have been condemned as "time-consuming, costly and 
wasteful" ([16]). Guy Fawkes is much less so than previous schemes; and there 
are applications for which it might be practical. 

Firstly, let us consider the most convincing proposal for a practical applica- 
tion of hash-based signatures. This is the method of Gennaro and Rohatgi for 
signing digital steams [21]. When signing a stream whose content is not known in 
advance to the signer (such as a television programme), they divide ihe stream 
into blocks; each block contains a one-time public key using the Lamport scheme, 
and is signed with the one-time private key whose public key was sent in the 
previous block. The first block is signed using a conventional mechanism such 
as RSA. In this way, a single conventional signature can be leveraged to sign a 
whole stream of data 'on-the-ny*. The authentication thus provided is fast, in 
that no use is made of asymmetric cryptography once the session is established; 
but it is bulky, as both a one-time public key and a one-time signature must be 
added to each block. 

The Guy Fawkes mechanism can be adapted readily to this application and 
can greatly reduce the amount of computation required; it can cope particularly 
well with bidirectional streams, such as in videoconferencing, although it also 
works well in applications where a stream is sent to a recipient who merely sends 
a series of acknowledgements. 

Here, our protection goals are that if any bit in the two streams is changed, 
both communicating parties will detect the problem; and that the authentication 
mechanisms are as fast as in Gennaro and Rohatgi's scheme without the message 
extension (in fact Guy Fawkes is faster). Finally it must provide non- repudiation 
as well as simple authentication; a third party observing the stream exchange can 
ascertain the information source and integrity, as opposed to symmetric MACs 
where the use of shared secrets makes mutual recrimination possible. 

In this protocol, Alice and Bob will exchange message streams consisting of 
sequential blocks which we will call Aq, Ai, A 2 , ... and B 0 , B\, B 2 , ... respectively; 
each block will be accompanies by authentication information to be described. 
Bi is sent after A* but before Ai+i . 

In addition, Alice will choose a series of passwords X 0) X\, X 2) ... ; she will 
commit to X { in message A*_i and reveal it in message A<+i. This commitment 
is called a* and has the form 

a,i = h(Ai+ u h(Xi+i),Xi) 

Similarly, Bob's commitments take the form bi = h(i?i_j_i, ft (Yi+i ),!*). It 
should be noted that Alice needs a buffer size equal to two blocks; to send 
message Ai she needs to know A i+ i in order to compute the hash value a*. This 
will not normally be a problem where, for example, each block is a frame of 
video. 
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The first steps of the protocol, which use conventional signatures to bootstrap 
the process, run as follows: 



A — ► B : Ao,ao,/i(^o),signA(Ao,/i(X 0 )) 
B — ► A : B 0 , b 0 , h(Y 0 ) ) siga B (B Q , h(X 0 )) 
A — ► B : h(bo,X 0 ) 
B — v A : /i(ao,lo) 

The authentication of each subsequent block now takes the following form: 

A — ► B : Ai,ai,/i(Xi),Xo 
B — > A : Bi,6i,ft(Yi),Yb 
A — ► B : h(bx,X\) 
B—>A:h(a u Y x ) 

Thus in this step, Alice has committed to the password X 2 (since a\ = 
h(A 2l h(X 2 ),X 1 ) and revealed the password X 0 ; this revelation authenticates 
Ai , while the commitment also refreshes the passwords. 

The security of this scheme follows inductively. Assuming faithful execution 
up to step n, and an attacker who tries to masquerade as Bob to Alice, having 
seen and intercepted the string B n , 6„, h(Y n ), Y n -\ . He cannot change B n as 6„_i 
contains a commitment to it; he cannot change 6 n as it contains as an input Y n , 
which he doesn't know but which was committed in 6 n -i; h(Y\) was similarly 
committed in 6 n -i; and if he forwards anything other than the correct value of 
Y n -i then this will fail to verify against b n and 6„_i. Similarly, he cannot in the 
next message forward anything other than the correct value of h(a n ,Y n ) as he 
does not know the value of Y n yet cannot change it, since it was committed at 
the previous step in n n _i. 

As a corollary, we obtain a protocol for authenticating a single digital stream: 
Alice sends the stream to Bob, and Bob simply sends an ack with a serial number 
as the text B n . 

There is one final subtlety. If all the passwords are eventually made known, 
then false content can be cut and pasted at will into a record of the exchange. 
In the basic protocol, we thus have something weaker that a signature, but 
stronger than symmetric authentication. This is an interesting fact in itself; an 
obvious direct application is witnessed communication, where (for example) a 
videoconferehce is also viewed by a third party who may be called on to testify 
about some aspects of it later. Another is in communication systems with third 
party logging, such as the SWIFT system mentioned above. 

However, our scheme can be converted quite simply into one with off-line 
nonrepudiation. The trick is a convention that each principal keeps secret their 
last password and reveals it to a judge in the event of a dispute. Alternatively, 
each principal could have a notary sign a hash of his last password together with 
a transcript of the session. 



8 



6 Other Practical Applications 

We now consider a number of other applications of our technique. 

6.1 An Integrity Equivalent of Diffie-Hellman 

Our protocol allows us to link a number of incidents securely, and so we ask 
whether it has any particularly interesting uses for the identification of principals 
in computer networks. After all, a principal is in some sense just the linkage of 
a series of incidents. 

In the real world, it is often only necessary to remember a certain distance 
back in such a chain. We may be quite unable to remember what incident first 
convinced us of the identity of our mother, or of many of our other relatives 
and friends; but the absence of a definitive initial authentication instance is 
considered to be irrelevant in such circumstances. Similar considerations may 
apply to electronic personae. Many people nowadays have built up relationships 
and even scientific collaborations over the net with other people whom they only 
later meet in person. 

The above protocol for bidirectional authentication shows how we can inter- 
lock hash-based authentication by two different individuals at the same time. 
One novel implication of this is that two principals who do not originally share 
any secret can protect the serialisation of the traffic between. Once this integrity 
channel is established, it will guarantee both the content and the correct serial- 
isation of all future messages. 

This channel does for integrity what the DifBe Hellman protocol does for 
secrecy. This may seem counterintuitive, and it certainly challenges the com- 
mon understanding that the l man-in-the-middle attack can defeat any protocol 
not involving a secret 1 [17]. What is actually happening of course is that a mid- 
dleperson attacking the integrity channel has to participate in it from the start; 
she cannot join in later, or the views that the two participants of the transaction 
history will differ in nontrivial ways. 

At the systems level, this is because we have set up a channel with integrity 
but no authenticity, in the sense that we do not know who we are speaking to. 
So Alice, who wanted to speak to Bob, might in fact be speaking to Charlie. 
However in this case Charlie will have to participate actively in the conversation 
between them for the rest of time if he wishes to escape detection; he will not 
be able to drop in and out of their traffic at will. 

There are applications in which conventional authentication may not be pos- 
sible and yet the limitation on active attacks that this technique provides might 
be valuable. An example is communication between dissidents in an oppressive 
country that compels the escrow of even signing keys. In such conditions, trust 
is likely to be built up slowly over a long series of messages, and users may well 
wish to be sure that a channel that they are starting to trust is not taken over 
by authority. 
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A curious feature of multiparty Guy Fawkes, however, is that when one prin- 
cipal introduces two others with whom he has established sessions, he cannot 
ever persuade either of them that the other actually exists. Alice, on being intro- 
duced to Bob by Charlie, could just as easily be introduced to another persona of 
the principal behind Charlie. This appears to be a feature of electronic commu- 
nications in general; it is merely brought out when we start to consider protocols 
for establishing trust that do not rely on some bootstrapping event in the physi- 
cal world. (The Rivest-Shamir interlock protocol is the only one we know of that 
can achieve a similar effect [24]; but previous comment on it has focussed on the 
understandable difficulty of using it for authentication [25].) 

6.2 Tamper-evident audit trails 

It is a well known problem that an intruder can often acquire root status by 
using well known operating system weaknesses, and then alter the audit and log 
information to remove the evidence of the intrusion. In order to prevent this, 
some Unix systems require that operations on log and audit data other than 
reads and appends be carried out from the system console. Others do not, and 
it could be of value to arrange alternative tamper-evidence mechanisms. 

A first idea might be to simply sign and timestamp the audit trail at regular 
intervals, but this is not sufficient as a root intruder will be able to obtain 
the private signing key and retrospectively forge audit records. In addition, the 
intervals would have to be small (of the order of a second, or even less) and 
the computation of RSA or DSA signatures at this frequency could impose a 
noticeable system overhead. 

In this application, the Guy Fawkes protocol appears well suited because of 
the low computational overhead (two hash function computations per signature) 
and the fact that all secrets are transient; this second's secret codeword is no 
use in forging a signature of a second ago. 

The envisaged architecture here is that each server or other sensitive machine 
on a LAN would authenticate its log and audit data once per second (or even 
more frequently) with a local timestamping service, that would run on a machine 
stripped of vulnerabilities such as sendmail. This could in its turn interact at 
some suitable frequency with an external machine such as a corporate time 
stamping service, which in turn could interact with a commercial service. The 
protocols for this are currently under development. 

6.3 Secure access to timestamping services 

Third party timestamping services have much wider uses than simply providing 
trust backup for audit data; they are used to provide evidence of priority for all 
kinds of intellectual property, financial records and other business documents. 
An example design of such as service is found in that of Haber and Stornetta 
[23]. There the messages to be stamped are hashed in a tree, with a hash of 
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all input messages being made available once a second over the web and once a 
week through a newspaper advertisement. A signer can incorporate the relevant 
part of this hash tree with the disclosure of his message in the same way that 
he would incorporate a collection of certificates. 

This immediately raises the question of how the user can trust that the 
timestamping service that appears to have incorporated her message into its 
tree is a genuine one, and not a simulacrum created by an attacker who has 
taken over her network connection. A conventional approach would be for the 
timestamping service to affix a digital signature to the timestamps it returns. 
However, this brings extra complexity into the trust loop, with possible attendant 
costs of licensing a digital signature technology. There axe also performance issues 
in signature generation when providing a service sized to generate a thousand 
timestamps a second, as Haber and Stornetta's system is; this can be provided on 
a workstation which will however only generate 50 RSA signatures per second. 

The simple solution is to use the Guy Fawkes protocol as a means of authen- 
ticating the timestamping service to the user. We are currently working on an 
implementation that will work with this timestamping service. 



6.4 Other applications 

Other specific applications in which the Guy Fawkes protocol might offer advan- 
tages over other integrity and nonrepudiation mechanisms include the updating 
of root keys used by software vendors and CAs; telegambling; digital elections; 
membership of clubs with optional anonymity; and software metering mecha- 
nisms in which a vendor sends 'keep-alive* messages to the systems of those 
subscribers who keep on paying their licence fees. The value that Guy Fawkes 
can provide here lies in the absence of a single short long term secret that a 
pirate could broadcast. 

Another family of applications is in general authentication and non-repudiation 
protocols where for cost reasons it is desired to use low-power processors, such as 
cheap smart cards or microcontrollers. In general, where we have an interactive 
application in which some combination of anonymity with either serialisation or 
temporary nonrepudiation is required, a protocol based on Guy Fawkes may be 
the tool for the job. 

Finally, given the politics of cryptography, it may be worth remarking that 
all secrets in the Guy Fawkes protocol become known; there are no long-term 
user secrets that can be used as decryption keys and thus less motive to attempt 
to escrow signing keys, with the consequential loss of evidential reliability. It can 
of course be used to detect middleperson attacks on Diffie Hellman:key exchange, 
and thus to set up confidential channels indirectly. However it is unclear that 
any nonrepudiation — or even authentication — can be achieved if preventing 
authentic Diffie-Hellman is a national policy imperative; even a simple password 
is enough to prevent middleperson attacks [22]. 
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7 Conclusion 



We have shown that it is possible to provide a non-repudiation service without 
public key mechanisms, tamper resistance or third party logging. We do not even 
require any principal to possess a long-term secret. 

This involves a new protection primitive which in its simplest form behaves 
extremely like a digital signature and may be obtained at a negligible compu- 
tational cost, provided that a timestamp service exists. We have also shown a 
bidirectional primitive that may be used to authenticate digital streams at much 
less cost than the previous best protocol. This led us to an 'integrity equivalent' 
of Dime Hellman: two users can under quite reasonable assumptions establish a 
channel whose traffic is protected against modification, without either of them 
possessing a secret at the start of the protocol or concealing any secrets from 
authority. 

Quite apart from possible applications, these constructions raise a number 
of interesting questions, such as: what exactly is a digital signature? what is 
the necessary role of communication in a public key infrastructure? and what 
tradeoffs are there between computation, communication and the maintenance 
of state? 
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